We don't want to tell you how you should debug here, as that's obviously a developer preference, but there are a few non-obvious hints about debugging that we wanted to get here. Many GeoServer developers just make use of log statements and java stack traces. Others can not work without a real debugger. For a tutorial on getting set up with GeoServer debugging see 5 Eclipse.

Better Exceptions

GeoServer comes configured to run quickly and is geared to users. A few things can be done to make GeoServer more friendly for debugging. The first is to turn the verbose exceptions on. This will make it so any ServiceException that GeoServer returns will include the Java stack trace. All requests used to do this, and then we realized that for even common errors it looked like something went completely wrong, from the perspective an end user. So we turned it into a configuration option. This can be set in the web admin tool (Welcome -> Config -> Server) or in the services.xml file. If the errors returned are really nasty, like from the Servlet Container and not normal GeoServer service exceptions, then we recommend editing the web.xml file in WEB-INF. This contains a 'serviceStrategy' param. This is the strategy used by AbstractServlet to return the response. SPEED is the default, which writes directly to the output. The problem is that any errors that take place during the actual writing will not return proper ServiceExceptions, as GeoServer will have already started writing. This is why the very nasty errors show up. To get a better error set it to FILE or BUFFER. FILE is more scalable, writing all responses to a temp file first, and if successful that is returned to the client. BUFFER just writes to memory, so it is faster, but memory bound. We were going to make this user configurable, but realized that you should only need non SPEED strategy if there are programming errors. If everything is working correctly then the writing of the response should not be the source of errors. Note that for version 1.3 we have configured verboseExceptions to also set the service strategy to FILE when set to true. So just setting that to true should produce much better errors, we are just including this for information on how things work, and for past versions.

Logging

The next hint is logging. GeoServer uses the logger that was added to Java 1.4. For debugging we recommend starting with FINE, and if that does not reveal the errors, put it to FINER. FINEST generally will reveal no more, as GeoTools will fill the screen with log statements from Factory construction, and little else of value is added. GeoServer uses a console logger, which means that when used in a Servlet Container it will write to whatever the container is configured to write to. So consult your container's documentation about logs.

Please feel free to add more!